        The following is the
       text of a SIG message
       that I left some months
       ago. The information
       about the naming of the
       file I now consider
       questionable, so I have
       enclosed it w/ square
       brackets. The example
       program works as
       intended...It hangs up
       the disk drive in an
       endless loop.

  Ive been expirimenting w/ the &
 command in the 1541 DOS with these
 results:
  (corrections welcomed!)
  The "&" Cmd. may be used to execute
 ML code in Disk ram from a file
 stored on disk. It will autostart on
 powerup in some drives, under certain
 circumstances.
  In my oldest 1541 the full code as
 shown in Abacus Disk book is present
 at disk Rom addr.s $e780-e852. The
 ROM in my SX however, eliminates the
 autostart portion between $e780 and
 $e7a2. The & CMD part is still there,
 it just wont autostart. The file to
 be executed is specially structured.
 *[It may be either a PRG  or USR
 file, (at least). The file must have
 "&" as the first character of its
 name.]* The first two bytes of the
 file are the the disk ram addr. where
 the file is to execute. The L	 t byte
 is a check sum formed on all the
 previous bytes (but not itsself)
 equal to the remainder after their
 sum is divided by 256. The third byte
 is the number of following prg. bytes
 , NOT including checksum byte.
 Example: Consider this do-nothing 3
 byte program that just loops on
 itsself and executes at $0400 => JMP
 $0400 . The & file would be (hex): 00
 04 03 4c 00 04 5a .The disk sector
 containing it would read (with the
 addition of the link pointers): 00 08
 00 04 03 4c 00 04 5a +bufferju	 ...
  If this file were named , say,
 "&drivehanger" it could be executed
 as follows:
 open15,8,15
 print#15,"&dri*"

 .. If you have trouble getting this
 to work,..try making the "&" file the
 first one on your disk. I am not sure
 that: print#15,"&dri*" is the correct
 syntax, but it does work when the "&"
 file is the first.


  In drives w/ the autostart code, the
 first "&*" file on the disk will also
 execute (at least w/ my equipment)
 under the following conditions:
 1. When connected to '64, bo	  off,
 then drive turned on. (oddly, it wont
 work unless cord is plugged into 64.)
 2. Disk ON, 64 OFF, autostart
 cartridge in 64 (hes mon), 64 => ON.
 (This is aparently the reason why,
 when I power up w/ hes-mon pluged in,
 I get disk error 'Record not present'
 ! ..that allways puzzeled me!)
 3. Both ON , cart. dont care, 64 =>
 OFF.
 4. Both ON , cart in 64, Hdw. RST
 performed. (sys64738 won't do it from
 basic w/ hes-mon)
   Uses for this?... How about
 combining w/ Spooling technique so
 that an	 solated drive and printer
 pair could print out a disk file?..
 This would need a "dead 64 simulator
 cable" pluged into the disk. Or how
 about an & file of several blocks w/
 the last links turned to point to
 first block... maybe an endless belt
 repacement operating system could be
 done this way? Other ideas?...


 ..a final note: in newer drives
 without the auto-start code, "&" has
 little to reccomend it over the easier
 to use Block-Execute Command. The
 exception being that it appears that
 a fi	  of more than 1 block may be
 executed.
